This glossary contains information about many terms, phrases, and abbreviations used by CygNet Software. Additionally, many sections of this Help document contain terminology and concepts that are related directly to the Help section you are viewing. See the following topics for additional specific assistance:
Browse by letter: A B C D E F G H I K L M N O P R S T U V W X
The terms 32-bit and 64-bit refer to the way a computer's processor handles information. The 64-bit version of Windows handles large amounts of random access memory more effectively than a 32-bit system.
CygNet Software provides support for two 64-bit services (a 64-bit Universal Interface Service (UIS), and a 64-bit Value History Service (VHS)) and all remote device drivers, communication device drivers, and import export drivers are available in 64-bit versions, with the exception of the SonicMQ Export EIE and the SonicQ EIE, which are limited to 32-bit. Note that only the driver portion of each EIE is 64-bit; the associated editor is not 64-bit.
For more information see Services Overview and 64-bit Device Drivers.
The Access Control Service (ACS) is the CygNet Software security administration service. Its database contains the list of applications and events for which security is required, as well as the list of users and their authorization levels. In terms of security each service is an application. Security can also be applied at the record level in a service. The ACS can provide security for custom applications provided they can communicate with the ACS. It functions in concert with the operating system security (Microsoft Windows) to protect access to your system.
For more information see Security.
The Address Resolution Service (ARS) is the CygNet Software directory service that resolves network addresses. It is sometimes called a metadata service since it resolves information about other CygNet services. The ARS must be running in order to install CygNet Software successfully. It tracks the network address and operational status of each service within a CygNet domain.
A service must be added to the ARS before it is started for the first time. This eliminates superfluous entries and enforces administrator security. You can view and modify ARS records using CygNet Explorer.
For more information see Address Resolution.
Security Supervisors File. For more information see Security Supervisors.
American Gas Association. Refer to the AGA website for more information.
Alarm condition is the same as point state, in that it is the highest precedented state for a point record as defined in the CvsMetadata file for the current point scheme, except that in the point state definition for each point state, the alarm condition attribute must be set to "true" for the alarm condition to be considered. When alarm condition is set to true, the defined point state is considered a valid alarm condition.
For a system running the default CygNet Standard Point Scheme (Point Scheme 0), point state and alarm condition closely follow each other. For example, when a point is in a High Alarm condition, the point state and alarm condition will both be High Alarm.
For the CygNet standard point scheme, three point state definitions do not allow alarm condition configuration: the Normal, Unreliable, and Uninitialized point states. For these three point state definitions, the alarm condition attribute is always "false," meaning that these point states will never be considered an alarm condition. So when a point is in a Normal, Unreliable, or Uninitialized state, the alarm condition will be blank.
For all other point state definitions, alarm condition is the highest precedented point state when alarm condition is set to true.
The following table lists the point state definitions that allow an alarm condition for the standard point scheme:
| Analog | Digital | Enumeration | String |
|---|---|---|---|
| High Alarm | Chattering | Alarm 6 | Alarm 6 |
| High Warning | Alarm | Alarm 5 | Alarm 5 |
| Low Alarm | Warning | Alarm 4 | Alarm 4 |
| Low Warning | Alarm 3 | Alarm 3 | |
| High Out of Range | Alarm 2 | Alarm 2 | |
| Low Out of Range | Alarm 1 | Alarm 1 | |
| High Deviation | |||
| EAC Prevented* |
*If enabled for CVS calculation, the "EAC Prevented" configurable bit will be set only if Enhanced Alarm Configuration conditions have been defined for this point, and the evaluation of those conditions has prevented one or more of the other enabled configurable bits from being set that otherwise would have been set.
In the CygNet Enhanced Point Scheme or other customized point schemes (Point Scheme 1 - 15), the alarm condition and other desired attributes (description, display order, associated state colors, etc.) can be configured in the CvsMetadata file as needed. See Understanding the CVS Metadata File for more information about configuring point scheme properties.
For more information also see Point State.
The Alarm Event Logging Service (ELSALM) is an instance of an ELS. Its purpose is to store alarm and notification events. It can be used to help you occasionally clear out the ELS without losing alarm history.
For more information see Logging.
Alphanumeric Page (associated with the GNS). For more information see Notification Types.
American Petroleum Institute. Refer to the API website for more information.
Application Programming Interface. See also CygNet API below. For more information see Scripting.
A person who can add, delete, and modify users and user permission levels contained in an Access Control Service (ACS). See also Access Control Service (ACS).
For more information see Configuring Application Administrators.
The Application Storage Service (APPS) is an instance of a BLOB Storage Service (BSS). CygNet uses this service to store client application files.
For more information see BLOB Storage Service.
For security-related purposes, CygNet services are considered applications. The application name is user-defined in each service’s configuration file, with the exception of the Address Resolution Service, which is named "ARS."
For more information see Applications.
Archive files are associated with the Value History Service, which can be configured to store value entries to separate compressed archive files. All values for all points are logged to a single compressed archive file for each day. Entries are written to the compressed archive at the same time they are written to the main history file, and may be retained for a specified time interval.
For more information see History.
American Society for Testing and Materials. Refer to the ASTM website for more information.
The Audit Service (AUD) tracks and stores all changes, such as what was changed, when it was changed, and the individual who made the change, known as the audit record. It logs operator actions and configuration changes, as defined for various services. The level of detail contained in an audit record is based on the service’s auditing configuration. The Audit Service does not audit itself.
Auditable actions include starting or stopping a service through the RSM, updating or deleting values in the VHS, setpoint changes, point configuration changes, etc.
For more information see Auditing.
Automatic full backups are user defined to a relative or absolute directory path, based on defined keyword parameters set in the applicable CygNet services’ configuration files.
For more information see Backup and Restore.
The RSM is expected to restart (or fix) any failed local service. This is accomplished via the Automatic Service Recovery feature of CygNet, configured for each service in the RSM. Whenever a service shuts down abnormally the RSM will attempt to restart the service via the recovery actions configured in the RSM. Automatic service recovery can be mass configured for all services in a Redundancy environment via the Automatic Service Recovery option in the Redundancy Editor.
A blackout is a period of time during which an action does not take place. Blackouts can be applied to scheduled tasks in the MSS and to notification recipients in the GNS.
For more information see Scheduling Blackouts.
Binary Large Object. For more information see BLOB Storage Service.
The BLOB Storage Service (BSS) is a CygNet service that stores files. Any type of file can be stored in a BSS, including .app, .bmp, .csf, .dll, .doc, .exe, .ico, .ini, .jpg, .ocx, .rpt, .rsp, .rsq, .xls, etc. The term BSS is used generically to describe any BLOB Storage Service (APPS, BSS, custom).
The CygNet services installation program sets up the host with two BLOB Storage Services: APPS and BSS. These services are the same type; they just have different names. The APPS is the repository for all of the CygNet client application files. The BSS is installed with no files and is intended as the repository for user files such as CygNet Studio screens, trends, etc. The reason that two BSS’s are created is to allow for differentiation of security and to separate CygNet applications from user data. CygNet Software recommends that users have read-only authorization to the APPS.
Only three items differentiate the APPS and the BSS:
For more information see BLOB Storage Service.
See CygNet Bridge.
British Thermal Unit. For more information about supported units see PNT Engineering Units or FMS Data Items Units.
Client Access License. For more information see License Management.
Canvas is CygNet Software's HMI (human machine interface) application.
Canvas provides high-quality screen design functionality, utilizing a variety of specialized tools and controls, which you can use to create user screens to interface with your CygNet Software installation and data. The Canvas plugin model allows the creation of custom or third-party control types, and once added to Canvas they will be available for addition to your screens.
Canvas View is the read-only run-time companion application to Canvas providing a standard multi-document interface to your Canvas screens. You can also open any CygNet Studio file (.csf) in Canvas View.
For more information see Canvas.
Flow-Cal formatted files. For more information see FMS Commands.
Common Industrial Protocol type used by an Allen Bradley CIP EIE.
A client is any network-based application that proactively accesses CygNet services. For more information see CygNet Client Installer.
Classified Message Incidence.
The Common Alarm Service (CAS) provides centralized alarm processing for current value services (CVSs). When a CVS receives a value for a point that meets or exceeds an alarm setpoint, the CVS reports the alarm to the CAS.
Alarm setpoints and alarm reporting are configured on a per-point basis in the point configuration record in the PNT. CygNet Explorer, CygNet Studio and CygNet Vision can be used to view alarms. The ELSALM stores alarm history.
For more information see Alarms.
Communication or comm devices are the communication interfaces between a host server and remote devices.
For more information see Communication Devices.
CygNet includes a communications statistic for monitoring the communications state, or comm state. This statistic reflects the state of the most recent communications with the device.
For more information see SYCSSTTN, SYCSSTAT, and Failed Comm Transition Period.
Communication statistics are calculated by the Universal Interface Service (UIS) and can be viewed in table form using the CygNet UIS View Control in CygNet Explorer or CygNet Studio. You can also create points for the statistics so that you can define alarms and notifications, as well as to report the values to the historian or to display them on CygNet Studio screens. Communication statistics can be monitored for both communication and remote devices. They are calculated from the last UIS restart, and most of the statistic types have options for current day (CD), current hour (CH), current month (CM), last day (LD), last hour (LH), and last month (LM) statistics. It is important to note that the statistics do not persist; that is, they are reset when the UIS is restarted. There is also an option to calculate rolling 20-minute window (2M) statistics; however, this feature must be enabled for the UIS.
For more information see UIS System UDCs, Remote Devices User Interface, Comm Devices User Interface, and Setting up 20-Minute Statistics.
Configurable status bits are used to facilitate CVS alarm functions and calculations, as well as CAS and GNS reporting. There are 15 configurable status bits that can be associated with a point record. See Point Status Bits and Configurable Status Bits for more information. Also see System Status Bits and User Status Bits.
A configuration file is a text file that defines a service, such as its name, associated services, file names, file size limits, etc. The configuration file is used by the service during startup. The contents of a configuration file are keywords and keyword parameters specific to the type of service.
For more information see Service Configuration Files.
Attributes of a service that define its configuration. For more information see Services.
Comma-Separated Values. It uses the file extension .csv.
Custody transfer data. For more information see CygNet Measurement or your device type in Remote Devices.
A Current Value Service (CVS) is a generic name for a data collection service that acquires data using data collectors, EIEs, remote devices, and communication devices, and stores the data in an internal table called a current value table. The CygNet current value services include the HSS, OPCIS, SVCMON, and UIS.
For more information see Current Value Services.
Current Value Table. For more information see Current Value Services.
The CygNet® IoT/SCADA platform collects, manages, and distributes critical real-time and operational data across your oil and gas enterprise. Using the CygNet platform, operators can process diverse data and information—from downhole sensors to surface facilities and pipelines. Users across every business function can prioritize and analyze real-time information to support strategic decision-making and optimized operations.
CygNet Business Object Builder. For more information see Enterprise Objects.
CygNet Software currently supports two Application Programming Interfaces (API). These automation libraries facilitate data retrieval, display and manipulation of the CygNet system via script:
Many CygNet Studio tools are considered CygNet-aware, meaning that they can be configured to show data for a particular point or points. These tools are referred to as primary point tools and their icon is designated with a small red "C." For more information see CygNet-Aware Tools and Primary Point.
CygNet Bridge is a set of services running outside of the CygNet production environment that is utilized by other CygNet products, namely CygNet Mobile, CygNet Dispatch, and CygNet Bridge API, to securely access CygNet SCADA and/or CygNet Measurement data and provide it to users who require data access but are external to a CygNet installation.
For more information see CygNet Bridge.
CygNet Bridge API is an optional CygNet companion product that enables developers to securely access CygNet system data over the web for integration into desktop, mobile, or web applications. CygNet Bridge API is available in conjunction with CygNet Bridge.
For more information see CygNet Bridge API.
CygNet Dispatch is an optional CygNet companion product to CygNet Measurement, that provides additional functionality to integrate results from field information that could potentially alter calculated volumes in your measurement data. CygNet Dispatch is available in conjunction with CygNet Bridge.
For more information see CygNet Dispatch.
CygNet Explorer is CygNet Software's main configuration and administration application. It provides an overview of your entire CygNet implementation while providing an interface for viewing data and modifying the records contained in the various services.
For more information see CygNet Explorer.
The CygNet GIS Control was an ActiveX control in CygNet Studio that displayed SCADA data on a customized GIS map made using a third-party tool, ESRI’s ArcMap. This control is now obsolete.
CygNet Measurement is a CygNet Software gas measurement application. It is used to produce accurate electronic flow measurement (EFM) data, to provide the best possible information to internal or external systems such as SCADA or production accounting. See also EFM below.
For more information see CygNet Measurement.
A highly efficient process of transmitting packets of information or data between CygNet services, clients, utilities, and other CygNet applications. Native CygNet messages are transmitted via Reliable User Datagram Protocol (RUDP).
For more information see Configuring Advanced Network Settings, CygNet Client to Server Communication, and CygNet Message Sniffer Lite Utility.
The CygNet Mobile Application Suite is an optional CygNet companion product that provides access to CygNet system data using the CygNet Operator mobile application, over a mobile device. CygNet Mobile is available in conjunction with CygNet Bridge.
For more information see CygNet Mobile.
CygNet Sales resources include Weatherford software sales account managers specializing in CygNet Software products and services.
Contact CygNet Sales via the Weatherford Production Software website, telephone, or email, as follows.
https://www.weatherford.com/en/products-and-services/software/
+1-805-503-4125
Refer to additional topics within this Help for more information about CygNet Software.
CygNet Support resources include Weatherford technical assistance analysts trained on CygNet Software products and services.
Contact CygNet Support via the online Software Support portal, telephone, or email, as follows.
https://softwaresupport.weatherford.com/hc/en-us
(Sign in with your credentials to create, view, or update Support tickets.)
+1-866-4-CygNet (+1-866-429-4638)
Refer to additional topics within this Help for more information about CygNet Software.
CygNet Training resources include Weatherford technical educators providing a variety of interactive courses and training services for CygNet Software products and services.
Contact CygNet Training via the Weatherford Production Training website, telephone, or email, as follows.
https://www.weatherford.com/en/products-and-services/production/production-4-0/training/
+1-805-503-4125
Refer to additional topics within this Help for more information about CygNet Software.
Data collector is a general term used for a program that updates values in Current Value Services. The data collector may be internal to the Current Value Service or may be a separate executable.
For more information see Current Value Services.
A point for which the value is acquired outside of CygNet. Each point is a monitor or sensor which can be hard or soft. A hard data point can be an actual monitor; a soft point can be seen as an application or software calculation. Data group elements from hard and soft points are normally recorded and logged to create a timestamp.
For more information see Points Overview and Device Template Files.
A data group is a collection of data group elements. Some groups contain only a few elements, whereas others may contain hundreds of elements. Modbus data groups are user defined. Native data groups are defined by the manufacturer’s protocol. The number of elements in a group may change if the device configuration changes (for example, you add I/O). All communication to and from a device is performed using data groups.
For more information see Data Groups and Ordinalized Data Group.
A DBS-based service is a generic name for a service that stores information used by other services. DBS-based services include the Audit Service (AUD), Device Definition Service (DDS), Facility Service (FAC), Group Service (GRP), Master Scheduling Service (MSS), Note Service (NOTE), Point Service (PNT),and Table Reference Service (TRS).
Other services that fall into this category structurally are the Access Control Service (ACS), BLOB Storage Services (APPS and BSS), Event Logging Services (ELS and ELSALM), and General Notification Service (GNS), although operationally they are considered administrative (ACS, APPS, BSS) and real-time services (ELS, ELSALM, GNS).
All DBS-based services use the same database engine, and have very similar configuration parameters and security administration. Each type of DBS has a unique database schema. This is defined in the Data Dictionary Language (.ddl) file. You can view the contents of the file but do not edit it. The .ddl file also defines the indexes for the service. The indexes are useful for searching the database.
The Value History Service (VHS) uses the same underlying data storage technology (ESE) as the other DBS-based services, but it is not considered a DBS-based service due to its unique archiving functionality.
For more information see Services Overview.
Data Communications Library (DCL). A core CygNet library that assists in the transmission of data between CygNet services, clients, utilities, and other CygNet applications. It also assists with seat registration and CygNet licensing.
For more information, see CygNet Messaging and CygNet Client to Server Communication.
The Device Definition Service (DDS) stores remote device, communication device, and text import records. The DDS and UIS have a one-to-one relationship. As such, to add another instance of a DDS requires that you add another UIS. The services’ relationship is defined in each service’s configuration file.
For more information see Devices.
The data group element ID (DEID). For more information see DataGroupElement.
Data Group Element. For more information see dgElements.
Device Identifier. A property of the specific remote terminal device. For more information see Devices Overview.
A CygNet system. For more information see Domains.
Device Template File, used to configure CygNet for specific field devices. For more information see Device Template Files.
See Dynagraph Cards.
A Dynagraph Card provides information about rod-pump well performance. Each card displays one complete stroke in a load versus position graph. Dynagraph cards are also called "DynaCards". Different types of cards can be polled from a device, though not all devices support all card types.
Several EIEs have a DynaCard (or Dynagraph Card) data group for retrieving rod pump data. Several CygNet device template files contain DynaCard-related elements and attributes for defining data retrieval from a DynaCard-enabled device.
The CygNet Dynagraph Viewer can be used to view dynagraph cards. The CxDynagraph API provides an alternative method of interacting with the CygNet Dynagraph Viewer. The DynaCard Library is a collection of cards collected by a field device and stored by a VHS card storage service.
See also Pump-Off Control below.
Electronic Flow Measurement. For more information see CygNet Measurement, Remote Devices, and/or EFM Data Items.
Enterprise Integration Suite. For more information see Enterprise Integration Suite.
Energy Load Forecasting. For more information see Energy Load Forecasting.
The Event Logging Service (ELS) is the CygNet Software service that maintains a journal of system events by logging system-generated events and user-defined events. There are four types of events: service, operations, alarms, and external.
For more information see Logging.
The Alarm Event Logging Service (ELSALM) is an instance of an ELS. Its purpose is to store alarm and notification events. It can be used to help you occasionally clear out the ELS without losing alarm history.
See Alarm Event Logging Service (ELSALM) above.
Enterprise Operations. For more information see Enterprise Operations.
An Equipment Interface Engine (EIE) is an advanced device communications programming code built to correspond to CygNet services via a specific data source, such as a remote terminal unit (RTU), programmable logic controller (PLC), etc. CygNet EIE drivers support direct serial, serial modem, serial radio, and transmission control protocol/internet protocol (TCP/IP) connections between the Universal Interface Service and the device. EIEs enable users to define, configure, and view real-time data during input/output data flow.
For more information see Devices Overview.
Microsoft’s Extensible Storage Engine (ESE) data storage technology. CygNet Software uses ESE for its DBS-based services and the Value History Service (VHS). For more information see Extensible Storage Engine.
An event is a command or group of commands specific to an application. For more information see Events.
The Event Logging Service (ELS) is the CygNet Software service that maintains a journal of system events by logging system-generated events and user-defined events. There are four types of events: service, operations, alarms, and external.
For more information see Logging.
In CygNet, the term "facility" is used to represent a logical grouping of data. A facility can represent an RTU, a flow computer, a meter, or a tank battery. It can represent a manufacturing line, a building, or a specific process. It can represent a collection of points that are not device-oriented, such as scripted points or OPCIS points.
For more information see Facilities Overview and Ordinalized Facility.
The Facility Service stores all facility information. This service is linked to and synchronizes with other services that use facility information, including the Device Definition Service (DDS), the Point Service (PNT), and the Universal Interface Service (UIS).
For more information see Facility Service.
Valid facility tag strings resolve to a facility in the system. The format of a facility tag string is Site.Service::FacilityID.
For more information see Tag String Formats.
Failover is the process of switching the domain on which the active server is running to a standby (or backup/redundant) server. Failover ensures seamless operation in the event of a planned or unplanned interruption in service. The purpose of a redundant environment is to support failover.
For more information see CygNet Redundancy and Failover.
Common file extensions are listed in the following table. For more information see ESE File Types.
| File Extension | Description |
|---|---|
| .cat | Catalog file |
| .cfg | Service configuration file |
| .cfx | Flow-Cal formatted file |
| .csf | CygNet Studio screen file |
| .csv | Comma-separated values file |
| .csw | Studio Workspaces file |
| .dat.edb | Data files. For DBS-based services, the file name is ServiceName.dat.edb (for example, MSS.dat.edb). |
| .ddl | Data Dictionary Language file (for DBS-based services) |
| .dll | Dynamic Link Library |
| .dtf | Device template file |
| edb.jtx | Transaction log files for DBS-based services |
| .exe | Service executable |
| .few | Workspace files in CygNet Measurement, used to save workspace settings and values such as Site.Service, window positions, configured command definitions, custom report definitions, and controls with their settings |
| .inx.edb | Index file for DBS-based service databases. The file name is ServiceName.inx.edb (for example, MSS.inx.edb). |
| .log | Log files. Each log file contains service information. The file name is ServiceType00#.log; the # symbol is that file's individual occurrence. |
| .tfx | Flow-Cal formatted file |
| .ts.edb | Temporary storage file for DBS-based services |
| .xml | Extensible Markup Language file |
The Fix Interface Service was a current value service that retrieved values through the Intellution Toolkit API. This service was retired in v8.1.0.
The Flow Measurement Service (FMS) is the CygNet Software service that retrieves data, including electronic flow meter (EFM) data, from various sources for CygNet Measurement. The CygNet Measurement system retrieves, stores, validates, estimates, analyzes, edits, and approves the data for reporting to external systems. The FMS service functions as the interface between the Microsoft SQL Server database and the SCADA system. Optionally, the supplied FMS internal database can be used in appropriate production environments. The FMS Service and the FMS Explorer (primary user interface), commands, and controls manage electronic flow meter (EFM) data for the CygNet Measurement application.
For more information see CygNet Measurement.
Force evaluation on update is an option to force an evaluation of each new value for reporting to the VHS, regardless of whether the point’s value or status has changed.
For more information see Reporting Options.
The ForeSite® web-based production optimization platform enables production maximization across your reservoir, well, and surface facilities through well optimization, well monitoring and surveillance, field service management, and predictive analytics features. ForeSite supports a variety of lift types, including ESP, Gas Injection, Gas Lift, Naturally Flowing, RRL, and Water Injection wells, supporting both surface and subsurface data. ForeSite integrates seamlessly with ReO, WellFlo, and CygNet IoT/SCADA software.
For more information refer to the Weatherford website or contact your Weatherford account manager. Additional information is contained in the ForeSite online help available from within the application.
ForeSite Edge® is a separately available IoT-enabled well automation and control product that extends controller functionality to provide autonomous management at the wellsite. Both ForeSite production optimization and CygNet IoT/SCADA platforms are leveraged by ForeSite Edge devices to drive continuous production performance. ForeSite Edge Mobile is also available as a companion app for ForeSite Edge.
For more information refer to the Weatherford website or contact your Weatherford account manager.
ForeSite Edge® Mobile is a companion app for your Apple iOS mobile phone that operates with ForeSite Edge installations in the field. The app allows you to use your mobile phone at the wellsite to connect to ForeSite Edge devices within communication range, using available on-site Bluetooth communication technology, to view and configure critical device communication setup data between ForeSite Edge devices and RTUs in the field.
For more information refer to the Weatherford website or contact your Weatherford account manager.
The CygNet Gas Measurement Repository (GMR) application is a previously offered CygNet Software product that was discontinued effective with the v8.5.0 release (in December of 2016). Equivalent GMR data support is now provided by CygNet Measurement (FMS), using "FMS Legacy" data groups in cases where only GMR support was previously available. Refer to prior versions of the CygNet Help document for information applicable to previously installed GMR systems.The CygNet Measurement (FMS) application is a newer CygNet Software product that supersedes GMR, and provides equivalent functionality (in REPOSITORY mode) or additional functionality (in FULL mode) for managing electronic flow measurement (EFM) data. See CygNet Measurement for more information. See also EFM above.
For more information see CygNet Measurement.
The General Notification Service (GNS) stores and processes notification messages. Notifications are triggered by the setting and clearing of alarm bits. Notifications are enabled on a per alarm basis in the Point Service (PNT). When a current value service retrieves a value for a tag, it checks the tag record for alarm and notification settings. If the report notifications option is enabled, it sends the tag’s real-time record to the GNS for processing along with the GNS identifier. The GNS builds and processes the notification. The notification message and its recipients are stored in the GNS. The GNS supports several types of notification messages including email, text message, voice message (via a Dialogic board or SIP server), and others.
For more information see Notifications.
See Gas Measurement Repository above.
The Group Service (GRP) is a database service that stores group hierarchies based on facility and device attributes. Hierarchies are made up of nodes, each of which has its own set of properties and attributes. The GRP can store numerous hierarchies and their respective nodes, all of which are available to the various CygNet services they interact with, like the Point Service (PNT) and Facility Service (FAC).
Although the GRP powers group hierarchy creation and storage, the GRP is largely a behind-the-scenes service. Hierarchies stored in the GRP are typically created and edited using the Group Manager utility. Its interface is friendlier than the GRP editor and it enables both high- and low-level interaction with group hierarchies (and the GRP).
Important: Although hierarchies can be edited within the GRP service using GRP editors, this is strongly discouraged. Instead, use the Group Manager utility to create and edit group hierarchies. See Group Manager Utility for more information.
In a CygNet SCADA context, a group is a collection of facilities organized into hierarchies. Facilities are included in hierarchies according to user-selected facility attributes and device attributes. Attributes can be defined in a way that makes sense in your organization. Specific attributes can then be chosen to identify levels in user-defined hierarchies. Hierarchies enable the collection and organization of information specific to the facilities and devices to which those attributes belong.
For more information see Groups.
Human-Machine Interface. For more information see CygNet Studio.
A Host is a computer that is running one or more CygNet services. For more information see System Administration.
A HyperPoint is a discrete value calculated from current point values in other Universal Interface Services. It is a real-time point whose value and state are determined by the execution of an associated HyperPoint script.
For more information see HyperPoint Scripting.
The HyperPoint Scripting Service (HSS) is a CygNet real-time service that executes custom scripting to calculate user-defined HyperPoints based on time-specified events or a change in the point value. Although the service configuration is similar to that of the Universal Interface Service (UIS), the HSS does not collect data from external devices. You can use the CygNet Explorer client application to edit the HyperPoint scripts and view the point values.
HyperPoints are configured as any other point by using the script editor built into the Point Service (PNT). When the HyperPoint script is configured on the HyperPoint property page in the PNT editor, you can compose, edit, and run a test simulation of the script. The HyperPoint script text is stored in the PNT database.
It is recommended that you host HyperPoints using the HSS rather than a UIS. This action will eliminate performance impacts on real-time data acquisition. The maximum point count for the HSS is 500,000 points.
For more information see HyperPoint Scripting.
Identifier. Used in conjunction with field names in the configuration files, editors, and property pages. One example is "Application ID."
A word used in a configuration file to activate a function or to specify a parameter. For more information see Service Configuration Keywords.
Kill the selected service. When a service is killed, a Microsoft Windows "stop" message is sent to the service. Only use if the service is not responding to a normal CygNet stop request.
See Remote Service Manager and Service Management for more information.
Light-Emitting Diode. CygNet Studio contains several LED-related tool objects for placement on screens:
For more information see CygNet Studio.
A CygNet application used to calculate the volume of natural gas, the mass of supercritical carbon dioxide, or the volume of petroleum liquids in a pipeline segment at any given time. The Line Pack application can also be used to calculate mass imbalance to aid in leak detection in the pipeline segment. Other optional calculations include: line pack at MAOP, line pack volume converted to energy content (natural gas only), line pack measured or calculated density (CO2 and petroleum liquids only), line pack volume converted to mass (petroleum liquids only).
For more information see Line Pack.
Link is the service used as the MQTT publisher by CygNet to send data to an MQTT server. For more information see Link.
The Long Point ID is one of two unique identifiers of a data point. The Long Point ID may be up to 31 characters. Valid alphanumeric characters are: A through Z (uppercase), 0 through 9, underscore ( _ ), dollar sign ($), exclamation point (!) and no spaces are allowed. See also Point ID below.
For more information see Point Identifiers.
The Master Scheduling Service (MSS) is the CygNet scheduler. It can be used to schedule UIS Command Tasks, Setpoint Tasks, or FMS Tasks. Tasks can be scheduled to be recurring, for a duration, based on a condition, or continuous. A task can be applied to a single device or multiple devices. Blackout periods can be applied to tasks.
For more information see Scheduler.
See CygNet Messaging.
Message Queueing Telemetry Transport (MQTT) is an extremely lightweight machine-to-machine/Internet of Things (IoT) messaging transport protocol. It uses the publish/subscribe protocol, which is designed for constrained devices (limited processor or memory resources) and low bandwidth, high-latency, or unreliable networks.
For more information see Link.
Network Address Translation. For more information see Network Address Translation.
An individual subunit of a component or navigation hierarchy. A Leaf Node is the lowest level node in a hierarchy, usually corresponding to a facility.
For more information see Groups Concepts.
The note feature is powered by a parent service, the Note Service (NOTE). A Note Service is accessible by means of CygNet Explorer. This service contains notes created within a single site or from multiple sites on the same domain, and is associated with one or more current value services (CVS).
You can associate as many current value services (i.e., UIS, SVCMON, HSS, and/or OPCIS) as you like with a single Note Service. However, each associated current value service can only be associated with a single Note Service. For instance, Note Service A can contain notes referencing data from both UIS A and UIS B. However, UIS A can only be associated with Note Service A and UIS B can only be associated with Note Service A.
See Notes.
Open Database Connectivity. For more information see ODBC.
Object Linking and Embedding. For more information see Third-Party ActiveX Controls.
OLE Process Control. Also Open Platform Communications. See OPC.
An OPC Data Access (DA) Server collects real-time data from a field device, and then makes it available to an OPC client. CygNet supports its own CygNet OPC (DA) Server.
An OPC Historical Data Access (HDA) Server collects historical data from a field device, and then makes it available to an OPC client. CygNet supports its own CygNet OPC HDA Server.
The OPC Interface Service (OPCIS) is a specialized CygNet current value service that provides connectivity of CygNet Software to a computer using the OPC Data Access (DA) or OPC Historical Data Access (HDA) specification-compliant server. The OPCIS is an OPC client associated with an external OPC server. It can have a one-to-one or one-to-many relationship with OPC servers through OPC groups. OPCIS features include:
CygNet supports its own OPC (DA) Server and an OPC HDA Server.
See OPCIS vs OPC EIEs for a feature-by-feature comparison of the OPCIS with the OPC EIEs (OPC EIE, OPC Comm EIE, OPC Lufkin EIE, and OPC Weatherford EIE) to help you decide which OPC option best suits the requirements of your enterprise.
For more information see OPC Interface Service.
Ordinal is a generic term for an identifier. In an analog output data group, the ordinal would represent a point number or channel number. The name of an ordinal is manufacturer, device, and data group specific.
For more information, see Data Group Ordinals and Facility Ordinals.
If a point has more than one value at exactly the same timestamp, CygNet stores the extra value only if it is different. For example, if a value is set to 1.01 @ 12:32:15.004, 1.02 @ 12:32:15.004, and 1.03 @ 12:32:15.004, the VHS will store all three values even though the timestamps are exactly the same. CygNet assigns each entry an ordinal to allow a differentiation between the three entries. The datastore would reflect the following:
| Value | Timestamp | Ordinal |
|---|---|---|
| 1.01 | 12:32:15.004 | 0 |
| 1.02 | 12:32:15.004 | 1 |
| 1.03 | 12:32:15.004 | 2 |
The VHS datastore only evaluates the last (i.e. largest) ordinal to determine whether to set a new value. If another value of 1.03 @ 12:32:15.004 is set, CygNet will not store this as a new entry with an ordinal of 3, as it is detected as a duplicate. However, if a new value of 1.01 @ 12:32:15.004 is set, the VHS datastore will identify this as a new value (and not a duplicate) since it only compares the value to the largest ordinal, which is the 1.03 value at ordinal 2.
You can ordinalize a data group if a remote device requires multiple instances of a data group. This means that you define the group only once in the template but can add multiple instances of it in the DDS. The term ordinal can also mean a facility. See Data Group Ordinals and Facility Ordinals.
An ordinalized facility is associated with the original remote device facility and is displayed on the Facilities page of the device editor. Ordinalized facilities must be created in or chosen from the Facility Service (FAC). See Device Facilities and Linked Facilities and Data Group Ordinals and Facility Ordinals.
The Address Resolution Service (ARS) that can confirm deletion of the service entry. A service can be deleted only from its owner.
For more information see ARS Redundancy.
The security authorization level required to perform an event. CygNet supports six permission levels: None (no access), Read, Update, Add, Delete, and Administrator (unlimited access).
For more information see Permissions.
Numeric Page. Associated with the GNS. For more information see Notification Types.
Proportional Integral Derivative control.
Programmable Logic Controller. For more information see Devices.
A point represents a discrete value that is user-defined and configured in the Point Service (PNT). See also Point ID and Point Type below.
For more information see Points Overview.
The Point Scheme defines the point types, point alarms, point statuses, and default colors for a CygNet domain. The information described in this Help is primarily for the CygNet Standard Point Scheme (point scheme 0). The Point Scheme is applicable only to the PNT as configured on the PNT Editor for each point. For more information see Point Scheme and Startup Files.
Point state is the highest precedented state for a point record as defined in the CvsMetadata file for each CygNet point scheme. Every point state definition available for a point scheme has the following attributes: ID, name, description, display order, token, associated state colors (single color, foreground color, background color), and an alarm condition.
The point state for a point record is based on 48 System, Configuration, and User status bits, which are associated with the four point types (Analog, Digital, String, Enumeration). A point record may contain up to 48 status bits, which are used to provide point status information about the point record in a Current Value Service (CVS) and the Alarm Event Logging Service (ELSALM). A point can be in multiple states at the same time, for example, in High Warning and High Alarm; however, the state defined to be the most severe is the one that is used for the point state (i.e., High Alarm, in this case).
The following table lists the common point state definitions for the standard point scheme. These definitions do not allow alarm condition configuration.
| Analog | Digital | Enumeration | String |
|---|---|---|---|
| Normal | Normal | Normal | Normal |
| Unreliable | Unreliable | Unreliable | Unreliable |
| Uninitialized | Uninitialized | Uninitialized | Uninitialized |
In the CygNet Enhanced Point Scheme or other customized point schemes (Point Scheme 1 - 15), the point state and other desired attributes (description, display order, associated state colors, etc.) can be configured in the CvsMetadata file as needed. See Understanding the CVS Metadata File for more information about configuring point scheme properties.
For more information also see Alarm Condition.
The Point ID is one of two identifiers of a data point. The Point ID may be up to 8 characters. Valid alphanumeric characters are: A through Z (uppercase); 0 through 9; underscore ( _ ); dollar sign ($), and exclamation point (!). After a point has been created, its Point ID cannot be changed. See also Long Point ID above.
For more information see Point Identifiers.
The Point Service (PNT) is the CygNet point database service used to set operational parameters for real-time points in the CygNet system. A point record contains all configuration information about a point, including the name of its current value service (CVS), its Facility, Uniform Data Code (UDC), the Short ID and Long ID, description, engineering units, history retention period, alarm setpoints, scaling factors, notification options, enumeration conversions, etc.
The PNT manages alarm limits, conversion coefficients, description information, and other parameters necessary for real-time monitoring and control. One PNT can store point records for any number and any type of current value service (CVS). A point is required to see the data on a CygNet Studio screen, in a report, in a trend, or on a web page.
For more information see Points Overview.
A point type may be defined as analog, digital, enumeration, or string. For more information see Point Types.
Most objects on a CygNet Studio screen can be configured to show point information from a specific point, such as a point’s value, timestamp, description, etc. This point is referred to as the object’s primary point. Tools that can be configured with a primary point are identified in the icon by a small red "C," such as the Text Tool. To show point information, an object must identify the point using a fully qualified CygNet tag string.
For more information see Configuring Point Identifiers.
CygNet software is a vital component of Production 4.0, the Weatherford production performance solution that delivers end-to-end control, data management, and advanced data analytics to activate field-wide intelligence and maximize production across your assets. In addition to the CygNet IoT/SCADA platform, Weatherford Production 4.0 products include the ForeSite optimization platform, ForeSite Edge IoT-enabled automation, ForeSite Sense intelligent sensors, and Flow Measurement water-cut and multiphase technologies.
For more information refer to the Weatherford website or contact your Weatherford account manager.
While the terms "property" and "attribute" are synonyms in general use, in CygNet these terms convey a more nuanced meaning.
A property refers to the aspects of a particular thing (facility, group node, point, etc.) with a predefined and shared meaning (for example, name, description, category, color, etc.), while attribute refers to the aspects of said thing with a configurable meaning. All facilities have a name and category; those are properties of a facility. Facility Attribute 1 can be configured to mean Order in Type or Route or Tank ID; it is an attribute.
Pump-Off Control (POC) uses dynagraph cards to view well performance. CygNet provides an application for accessing and viewing these cards.
For more information see CygNet Dynagraph Viewer.
Process Variable. For more information see EFM Data Items in the Remote Devices section.
Reference Address (associated with the GNS). For more information see Notification Types.
A Real-Time Record (RTR) is the record structure that is entered into a current value table and stored within the UIS. An RTR consists of the point ID, description, value, measurement unit, timestamp, and status.
For more information see Viewing a Real-Time Record.
CygNet Redundancy achieves continuous operation of all CygNet services in the wake of component failure in the system, whether failure is due to normal operational transition of data from one location to another (via replication to move data from a primary server to a DR server, or backup, or forwarding, etc.), or due to an unforeseen natural disaster.
Each site in a CygNet environment runs on a unique domain and each domain is assigned a specific role: Active, Local Standby, or Data-Center Standby. When a failover is triggered (either manually via human intervention or automatically triggered without warning), all sites will swap domains, and assume a different role. Clients will always connect to the same domain, regardless of where the domain is running, and not have to make any changes as the result of a failover. CygNet redundancy operates on top of the CygNet replication model and is supported by underlying replication functionality, although replication is disabled for all services in a redundant environment.
For more information see CygNet Redundancy.
CygNet supports the ability to resolve and/or display information about a facility that is different from the facility of the configured point for an object. For any given facility you can define a path to another facility within your CygNet environment based on an attribute and a definition.
Known as Reference Facilities and Relative Facilities, these concepts are similar, but the implementation and configuration of each differs.
For more information see Reference Facilities and Relative Facilities.
Remote devices are the field RTUs and PLCs. Remote device component-level security is administrative security, governing factors such as who can change a device's configuration. See also RTU and PLC.
For more information see Remote Devices.
The Remote Service Manager (RSM) is used to control other CygNet services. It is sometimes called a metadata service since it manages information about other CygNet services. Service control can be on the local machine, on other machines in the local data center, or on machines in a remote data center. CygNet Redundancy functionality is handled by the RSM.
For more information see Remote Service Manager.
A Remote Terminal Unit (RTU) is a device that collects data from data acquisition equipment and transmits real-time values to the main system over a wired or wireless network to be stored and processed by the UIS.
For more information see Facilities Overview.
Remote Operations Controller; ROC also is the product name for a class of RTUs produced by Emerson Process Management (formerly Fisher).
For more information see Emerson Roc EIE or Emerson RocPlus EIE.
A Roll-down Point is a basically a shadow point. It takes the data from the Device Facility and rolls it down to a point for a Linked Facility.
For more information see Roll-Down Points.
Group rollups enable the "rolling up" or aggregation of information from the leaf nodes of a hierarchy to designated summary root- and sub-group nodes in the Group Service (GRP). When a rollup request is issued, it moves down the hierarchy to all relevant leaf nodes (facilities) searching for specified uniform data codes (UDCs), then rolls back up the hierarchy with the current value collected from the leaf nodes' specified current value service. This information is used to calculate totals, averages, and facility alarms.
For more information see Group Rollups.
CygNet Software is a Supervisory Control and Data Acquisition (SCADA) system that collects and manages critical real-time and operational data.
A seat is a computer that is running one or more client applications. For more information see Managing CALs.
A person with the authority to assign Application Administrators and to add applications and events to an Access Control Service (ACS).
For more information see Security Supervisors.
A CygNet service performs pre-defined transactions in response to client requests and is responsible for acquiring, storing, organizing, and saving data. The CygNet Software application consists of 23 services that perform interrelated functions. CygNet services are categorized into five basic operational service types:
For more information see Services Overview.
The Service Monitoring Service (SVCMON) is a specialized current value service that provides a method to monitor many system, service, and site statistics. The SVCMON can be used to perform service health checks, check ping times, monitor disk utilization, software and operating system version numbers, memory usage and ping times. Attributes of specific services can also be monitored, such as VHS database utilization and percent full, pending GNS notifications, total points and maximum points for current value services, and Address Resolution Service license counts.
Additionally, the SVCMON supports a defined set of calculation types. Point tags can be added to monitor deltas and rate changes. For point tags that represent file sizes, items can be scaled. The maximum point count for the SVCMON is 500,000 points.
For more information see Service Monitoring.
Session Initiation Protocol (associated with the GNS). For more information see Configuring VoIP Properties.
A site is a collection of CygNet services. (The site name is a property of the service.) A service name can contain up to 8 alphanumeric characters. Valid alphanumeric characters are: A through Z (uppercase); 0 through 9; underscore ( _ ); dollar sign ($); and exclamation point (!). Services can be grouped into sites based on geography, division, region, functionality, etc.
For more information see Services Overview.
SMTP Mail Address (associated with the GNS). For more information see Notification Types.
Simple Network Paging Protocol. For more information see SNPP Messages in the Notifications section.
SNPP Message (associated with the GNS). For more information see Notification Types.
CygNet supports several different status flags or words, each containing Boolean bits, which are used to provide status information about a point record in a Current Value Service (CVS). Each point record has 48 associated status bits. Status bits are defined in the point scheme. There are three types of status bits: System Status Bits (17), Configurable Status Bits (15), and User Status Bits (16). See Point Status Bits for more information.
Session Traversal Utilities for NAT (associated with the GNS). For more information see Configuring VoIP Properties.
System status bits denote miscellaneous state information about a point in the CygNet system, including:
There are 17 system status bits that can be associated with a point record. The bit IDs for status bits are predefined within CygNet and should not be changed. See Point Status Bits and System Status Bits for more information. Also see Configurable Status Bits and User Status Bits.
In CygNet a System UDC is used to create tags for:
System UDCs are intrinsic to CygNet and are not mapped to elements in the DDS.
For more information see System UDCs.
A field for which the selections are contained in a list box. The selections in the list box are contained in a table. The name of the table that contains the selections for the box can be displayed by placing the pointer over the field.
The Table Reference Service (TRS) stores selections for table-driven fields and Uniform Data Codes (UDC). Some table fields are system-defined. Others are user-defined.
For more information, see Tables.
Most objects on a CygNet Studio screen are used to show point information. To do so, an object must identify the point using a fully qualified CygNet tag string. The recommended tag string format is the Facility Tag String.
For more information see Tag String Formats.
Transmission Control Protocol/Internet Protocol. This protocol is used to identify network addressing and is monitored by the Address Resolution Service.
For more information see Network Addressing.
Timestamps are used to denote the date and/or time at which a certain event occurred.
For more information see Timestamps.
Flow-Cal formatted files. For more information see FMS Commands.
The CygNet Studio screen.
For more information see Using TheFrame TheView.
Logical collections of data accessible in a Emerson ROC or Emerson ROCPlus database. TLP stands for point type, location/logic, and parameter. TLPs use a unique referencing scheme that associates a point type number, logical (or location) number, and parameter number in order to specify a TLP location.
For more information see Emerson ROC Generic TLP Data Group and Emerson ROCPlus Generic TLP Data Group.
A token is a piece of code that may be substituted for a dynamic string of text. A token represents an attribute of a point, the point’s CVS record, or its Facility attributes. For example the token %Description% can be used to substitute for the Description of a point in many locations in CygNet Software.
For more information see Using Text Tokens or Using Tokens in Notifications.
A data group can be configured to retain Transaction Records. A Transaction Record is a record of the data requested from or sent to the device. Transaction Records can be viewed only from the Transaction field in the data group’s View Data dialog box. The number of Transaction Records retained is defined by the data group’s Transaction retention settings. The records are processed on a first-in, first-out basis.
For more information see Data Groups.
A trend provides a way to create a graphical representation of data change over time. Trends provide a (usually) customizable means to chart data in a number of useful formats, including line graphs, bar graphs, and area graphs. Trending capabilities are used by number of CygNet applications.
For more information see Trend Tool.
A UIS command is a means to perform a specific action using a data group. A command can be used to retrieve data, send data, or both, among other things. UIS commands are configured per device, per facility.
For more information see UIS Commands.
Uniform Data Codes (UDCs or data codes) are CygNet’s version of uniform product codes. They represent a method for standardizing data identification. See also System UDCs above.
For more information see Uniform Data Codes.
The Universal Interface Service (UIS) is the primary interface between field devices and CygNet devices. As the primary data collection service, the UIS is often called the "workhorse" of the CygNet system. It collects data for the devices stored in the Device Definition Service (DDS) and can store real-time records for up to 500,00 points for a 32-bit UIS and 5,000,000 points for a 64-bit UIS.
Using CygNet Explorer, you can view current values for device points, as well as various device statistics for remote, communication, and import/export devices. The UIS works closely with the DDS and Master Scheduling Service (MSS), among other key services.
Both a 32-bit UIS and a 64-bit UIS are available.
For more information see Universal Interface Service.
User Account Control (UAC) is a Microsoft Windows security infrastructure that limits user account privileges to enhance application safety. This is enforced by requiring administrator privileges to be assigned for the application(s), in order to perform certain administrative tasks. Refer to Microsoft online documentation at https://msdn.microsoft.com/for more information about UAC.
For more information see CygNet and User Account Control.
User status bits are configured by a user to associate special status information about a point. There are 16 user status bits that can be associated with a point record. See Point Status Bits and User Status Bits for more information. Also see Configurable Status Bits and System Status Bits.
CygNet provides many stand-alone and command-line utilities to help manage your CygNet installation, including tools to help with the following tasks: installing software and updating hosts; host and license management; service diagnostics, monitoring, and management; database and file management; service configuration file management; communication device, remote device, and device template management; data group management; facility and group management; point configuration and management; data export; auditing and logging management; replication and redundancy management; and much more.
For more information see Utilities.
Voice Address (associated with the GNS). For more information see Notification Types.
The repository for historical data in CygNet Software is the Value History Service, also known as the CygNet Historian or the Enterprise Historian, or simply as the VHS. History reporting is configured on a per point basis. Reporting options are properties of the point configuration record.
For more information see History and PNT Editor - History Page.
Voice over IP (VoIP) is a technology for the delivery of voice communications over Internet Protocol (IP) networks, such as the Internet. The CygNet General Notification Service (GNS) supports voice messaging for notifications via the SIP transport and media transfer protocols.
For more information see SIP and Configuring VoIP Properties.
The CygNet Well Test Module is integrated with the CygNet SCADA system to track oil, water, and gas (OWG) values for wells in a production facility. See Well Test for more information.
Extensible Markup Language.
|
|
|
